A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by any one of the patent disclosures, as it appears in the U.S. Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever.
A computer program listing appendix on compact disc is included as part of this application and the contents of the compact discs are incorporated herein by reference in their entirety for all purposes. The computer program listing appendix includes two compact discs (including duplicates) that are identical copies of each other. Each compact disc contains a file named xe2x80x9cAppendixA.txtxe2x80x9d, created on Nov. 15, 2001 and having the size of 42,689 bytes.
The present invention generally relates to software configuration management systems and more specifically to implementing fine grain versioning within software configuration management systems.
Configuration management plays an important role in the development of most software products. In particular, configuration management tools, such as Source Code Control System (SCCS), Revision Control System (RCS) and ClearCase by Atria, provide versioning tools that regulate and manage how software is developed by tracking the updates and modifications that are made to the software components managed by the tools.
For example, in a typical software development project, for a particular product or software release, many different software components may need to be generated. Typically, numerous software developers are involved in the generation of the software components in a software release. To facilitate software development, the software developers are typically allowed to access and modify many of the same software components. To provide for common access, the software components are commonly maintained in a data repository that is accessible by the different software developers. The data repository may reside on a single computer system or may be maintained across multiple computer systems.
For most configuration management systems, such as SCCS, RCS and ClearCase, the versioning tools are file-based and therefore provide versioning at a file level granularity. When a software developer wants to modify a particular software component, he or she is required to xe2x80x9ccheck-outxe2x80x9d the file that includes the software component. In checking-out the file, a new xe2x80x9cversionxe2x80x9d of the file is generated and brought into the software developer""s current work area. The software developer may then update and modify the file as necessary. Thereafter, the software developer can make the modifications visible to the other software developers by xe2x80x9cchecking-inxe2x80x9d the new file version back into the data repository.
As a file is repeatedly checked out and checked back in, numerous versions of that file will be generated. The files that are versions of a particular file are collectively referred to herein as the xe2x80x9cversion setxe2x80x9d of the file.
A drawback with using a file-based versioning tools is that certain data or information does not fit within the file-based paradigm, and therefore cannot be effectively managed within the configuration management systems that are tied to the file-based paradigm. For example, file-based versioning tools do not provide versioning at finer level of granularity than files, such as versioning of the individual software components within files.
During the first phase of a project, a set of requirements is often generated to ensure that all of the project goals are met. Each requirement may then be mapped to a particular function or software component using a spreadsheet, database or other mapping mechanism. In this manner, the mapping can be performed by linking each spreadsheet cell or table entry with a particular software module. Once the requirements are mapped, a second phase is initiated in which the software developers proceed to develop software components for which the requirements have been mapped. However, because the requirement mapping is performed at the requirement-to-component granularity, and not at a file level granularity, if a software developer determines that a particular requirement should be performed by a different software component, or that a software component should be split into two separate components, the requirement mapping can quickly become outdated as the file-based versioning tool will not maintain a correct mapping.
Another drawback with file-based versioning tools is that they do not support versioning at a level of granularity that is coarser than individual files, such as versioning of groups of related files. For example, FIG. 1 illustrates a system 100 in which a conventional versioning control mechanism has been implemented. In this example, version sets 104, 106, 108 and 110 respectively correspond to files A, B, C and D. As depicted in FIG. 1, for many file-based versioning tools, such as RCS or ClearCase, a stripe or label 102 may be generated which includes a particular version of each file within the data repository. The stripe or label 102 may represent a particular product or software release. However, because file-based versioning tools such as RCS or ClearCase can only perform versioning at the file level granularity, to use the strip or label as part of another system, the file versions that belong to the stripe must be manually copied into a separate data repository. Thus, the correlation between the file versions within the stripe or label and the file versions copied into the separate repository are lost.
Based on the foregoing, there is a need to provide a configuration management system in which versioning of software components can be performed at finer and coarser granularities than is provided by the conventional file-based versioning systems.
The foregoing needs, and other needs and objects that will become apparent from the following description, are achieved in the present invention, which comprises, in one aspect, a method for implementing fine grain versioning within software configuration management systems, the method comprising the computer-implemented steps for converting a non-versioned schema to a version-enabled schema. The method includes reading a first set of table definitions that belong to the non-versioned schema. A second set of table definitions is generated for the version-enabled schema such that each table definition in the second set of table definitions corresponds to a table definition in the first set of table. Each table definition in the second set of table definitions includes columns that correspond to the columns of the corresponding table definition in the first set of table definitions and one or more additional columns for storing version information.
In another aspect, a method for providing version support for objects stored in a relational database system is provided. The method includes creating a table that includes a first set of one or more columns for storing values that correspond to attributes of objects, and a second set of one or more columns for storing object version information. Multiple versions of a particular object are stored within the table. In response to a request from a user to retrieve the particular object, a version of the particular object to present to the user is determined based on a workspace associated with the user. The version of the particular object is presented to the user without exposing values from the second set of one or more columns to the user.
The invention also encompasses a computer-readable medium, and a computer system, configured to carry out the foregoing steps.